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PCT/US98/08407 


OPERATING RESOURCE MANAGEMENT SYSTEM 

CRQSS-RgFE RHNCETO RRI,ATHD APPLTCATfnN5; 

The present ^plication claims priority fh>m provisional application 
no. 60/044,372 filed April 28, 1997. 

TECHNICAL FTRm 

The present invention is a software system for procurement of opiating 
resources and, more particularly, is a software system that automates the cycle of 
(grating resource acquisition. 

BACKGROUND 

Today, operating resources account for as mudi as a third of a sales 
dollar in the typical Fortune 1000 company. Nearly 95 percent of all goods and 
services purchased by corporations are done so through paper-based processes. 
Predominant use of p^)a'*based buying is evidence that legacy business-to- 
busmess electronic commerce systems do not provide a solution for the bulk of 
corporate buying processes. Research UKlicates that a cost savings of 5 percent in 
operatmg resource goods and services cost will commonly result in a 28 percent 
increase in a company's profits. 

Traditionally, methods of purchasing operating sources (e.g., industrial 
supplies, office supplies and other non-production supplies) are extremely 
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fragmented and, thus, inefficient What is desired is an integrated, enterprise- 
wide solution. 

SUMMARY 

With the present invention, electronic automation, consolidation and 
leveraged buying through operations resource management (ORM) present a 
significant opportunity for companies to lower costs, and thereby dramatically 
enhance the bottom line. 

Operating resource management rq)laces the traditional, fragmented 
methods of purchasing operating resources. Through new technology - in one 
embodiment, namely intranets, extranets and Java" - operating resource 
management supersedes decades of inefficiency with a consolidated corporate 
electronic commerce system, to fully capture economies of scale and leverage 
supplier relationships. The operating resource management system of the present 
invention provides at least three key benefits: 

■ Automation of the entire acquisition cycle by incorporating all of 
the functions that make up the purdiasing process, from request through 
payment. 

■ Reduced operating resources costs through economies of scale 
and facilitation of a shift m purdiasing professionals* roles from tactical 
transaction processing to strategic supply-diain management 

■ Leverage of existing enterprise systems and electronic commerce 
systems through easy linkage to existing data sources, as well as siq)pliers' 
electronic commerce systems. 
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B RIEF PgSCRrPTION OF THE DRAWINGf; 

Figure 1 shows the engineering architecture of an embodiment of the 
invention. 

Figure 2 shows the extensibility architecture of an embodiment of the 
invention. 

Figure 3 shows the procurement process flow of an embodiment of the 
invention. 

Figure 4 shows the product feature description of an embodiment of the 
invention. 

Figure 5 shows the user environment features of an embodiment of the 
invention. 

Figure 6 shows the system environment features of an embodiment of 
the invention. 

Figure 7 shows the business modules included in an embodiment of the 
invention. 

Figure 8 shows the system ad^ters of an embodiment of the invention. 
Figure 9 shows the installation and implementation conqirehended in an 
embodiment of the invention. 

DETAfLgD DESCRIPTION OF THE PREFER RED EMBOHTMPNT 

In one embodiment, the opa-ating resource management system in 
accordance with the invention is a suite of software modules that automates the 
purchasing of goods and services within a corporation. Preferably, some of the 
modules qperate on a sexwcr compute of a network and othm of the modules 
operate with the system of die present invention, a company can reduce the cost 
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of transactions and increase overall productivity, with direct benefit to the bottom 
line. 

Some key featm-es of the system are: 

■ Walk-up User Interface on Any "Desktop" in the Company - 
The user interface makes the product accessible to employees with little or no 
training, helping and guiding the employee dirough the requisitioning process. 
Use of the system need not be limited to a select purchasing group. 

■ Ubiquitous and Easy Information Access for All Employees - 
Requesters and approvers alike can see the current state of any of their 
requisitions at any time and, thus, are always kept m the loop when something 
changes about their requisition. 

■ Authenticated Approval Flow - The system enforces the 
corporation's business rules and validates requisitions, ensuring accurate and 
complete data. 

■ Adapters For Integrating with the Enterprise - The system 
provides adapters to integrate the system into legacy enterprise data sources such 
as ERPs, Human Resource Management Systems (HRMSs), Email systems and 
directory services. 

■ Extensibility and Flexibility - TTie system provides complete 
flexibility in describing the data fields and busmess rules of each mdividual 
company. 

Referring to Figure 1, in the embodiment 100 shown thwein, a key 
module is an Enterprise Commerce Server 102, whidi includes Intranet 
application server software, preferably written in Java. A set of associated client- 
side software applications are also preferably written in Java. The Java client 
software 1 12 preferably runs in a Web browser (or, alternatively, is accessible 
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via the web browser), on every desktop (shown in Fig. 1 as "Mac", 'Winas*, 
"WinNT" and "Unix"), and provides the user interface for opting and 
approving requisitions. The Java server software 102 preferably runs on a single 
shared machine, and provides "back-end" services. 

Supplementing the Enterprise Commerce Server 102 are a number of 
Adapters 122, which integrate the system 100 into legacy enterprise data sources 
such as ERPs, HRMSs, E-mail systems and directory services. TTie system 
design is modular, allowing for any number of adapters to be plugged in without 
requiring revisions to the Entwprise Commerce Server software 102. 

In practice, the system in accordance with the invention is easy to use. 
The system is accessible both to infrequent users, people who buy something only 
once or twice a year, and frequent users, purchasing agents, administrators, and 
others who will use the system nearly daily. 

Most users of the system will be requisitioners: enq)Ioyees who need to 
buy something. Most of these requisitions are casual users will enter 
requisitions, via the client software 112, using a requisition wizjard. Figure 2 is a 
system diagram that shows generally how frmctionality (particularly functionality 
that can be extracted for a particular implementation) is apportioned in one 
embodiment of the system. Reference num^ 202 designates the requisition 
wizard module. 

Figure 3 is a flowchart that shows how a requisition is processed in a 
typical embodiment, from requisition creation to approval, to receipt of 
requisitioned goods/services, and to reconciliation. In Fig. 3. the ref^race 
numeral 302 designates process stq)s associated with cheating a requisition. 

Figure 4 is a top-level "product feature" description of an embodiment 
of the invention, while Figures S to 9 are diagrams that show the product features 
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at a more detailed level* As can be seen fix)m Figure 5, the wizard software is 
within the "requisitions" ponion 502 of the user environment 500. 

The wizard 202, 302 "walks" an employee through a number of 
questions to guide him through the process of making a purchase. For example: 

■ What do you want to buy today? 

Generally, the first question is "what do you want to buy today?" The 
wizard 202, 302 offers several ways to find the answer, always encouraging 
employees to choose from ^proved items. Perhaps the en^>loyee will just 
choose an item from a list of his own personal favorite frequently-ordered items 
304. Or perhaps he will be able find an appropriate item by searching through 
the product information database 306. Or perhaps he will find the item by 
looking through a number of approved on-line catalogs 308. (In one 
embodiment, the system supports such on-line catalogs, but does not itself include 
any catalog authoring tools.) 

Preferably, only as a last resort will the wizard prompt the employee to 
type in the name of a supplier and part explicitly (310). Entering such ad-hoc 
items, items that are not in the list of ^proved items, will typically trigger new 
approval rules. For exanq)le, the ^proval rules of many companies will cause 
the Purchasing Dq)artment to be put into the approval loop at this pomt, to 
require a Purchasing Agent to decide whether to approve the new item. Because 
ad-hoc entry usually involves additional overhead, the wizard guides the 
employee through the process in such a way as to avoid ad-hoc entry whenever 
possible. 

■ Who is going to pay for this item? 

Anothw inq)ortant pan of the requisition is the accounting information: 
who will be paying for the item. The accounting structure typically varies from 
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company to company, be it Division, I>q)artment, Account, or Project The 
wizard can be configured to display and ask for diffwent accounting fields for 
each company, helping to ensure that the employee will always be presented with 
choices that are relevant and appropriate. 

TTie wizard continues in this vein, asking questions and gathering other 
data about payment, billing, shipping, and the like. Throughout die process, the 
emphasis is on browsing and selecting, rather than typing, on channeling the 
employee toward standard answa^, and on generating error-free requisitions. 

Any employee who handles a requisition, be it requester or approve, 
can add commentary or attach documents to the requisition. TTie ability to 
conunent and explain can go a long way toward maintaining alignment, making 
requisitions understandable to improvers, allow approvers to provide feedback to 
requesters, and help approvers make a decision about whether to approve the 
request. 

After a request is submitted, another piece of user interface software 
500 comes into play: the Organizer 504 (Figure 5). In a preferred embodiment, 
the Organizer 504 software provides a folders-style view of existing requisitions, 
designed to help group and organize large collections of requisitions. 

When a request is submitted^ ^proval software (q)proval engine 110 in 
Figure 1; step 322 in Figure 3; approval flow software 602 of the system 
environment 404, in Figure 6) inspects the approval rules of the company, 
decides who needs to approve the request, and notifies the first required 
approvers, prefwably by e-mail, dm there is a requisition waiting for their 
attention. In oi» embodiment, the e-mail notification message indudes a URL 
hyp^link diat points die approver direcdy to the Organizer software 504 via his 
browser, to display the requisitions waiting for this pmon*s ^pioval. TTie 
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approver can approve or deny, and make comments, asking for more information 
or clarification. 

Whenever there is a status change in a requisition, notification software 
120 sends an e-mail message notifying the requester and any other interested 
parties. The system uses notification e-mails throughout the q)pr6val process to 
keep users informed about the current state of a requisition. Requesters can also 
use the Organizer software 504 to check the status of a request at any time, to 
keep apprised who has or has not 2q)proved it, when it has been fully jqjproved, 
and so on. 

Using the Organize 504 and the commenting mechanism, everyone in 
the ^proval process (e.g.. approvers, requisitioners, and Purchasing Agents) can 
ask each other questions, view the status of a requisition, or make comments 
about the requisition, reducing confusion and improving communication. 

After a requisition is fully approved, supplier interfece software 330 
communicates with die suppliers to give them the order. The system may 
communicate with supplier systems via conventional means, such as fax and 
e-mail. When a requisition is completed, the system will check the requisition to 
determine which suppliers are involved, determine the prefOTed method of 
ordering for those suppliers, and use that method for transmitting the requisition 
to the suppli^. Tlie pieces of the system used to transfi^ orders for fulfillment 
are known as the ordering modules 130 (Figure 1) (see also. Fig, 7). 

There are tfiree ordering modules 702 (see Figure 7): a Purchasing Card 
module, a Direct Order module, and a Purc^iase Ord^ module. 

Eventually Ae requisition will be approved, submitted, and fulfilled. As 
discussed above, the system may communicate ordors to the suppli^ via 
conventional means (fax and e-mail). But once the item is sh^^>ed, and arrives 
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on the requisitioii^*s doorstq>, receipt of the item must be acknowledged before 
payment is made. 

The system includes a user interface for acknowledging receipt, which 
allows employees to acknowledge that various items have been received. TTiese 
desktop receipts are all stored in the system and not integrated with the ERP. 

In addition to the requisitioning population - the requesters and 
approvers - there is another class of users: members of the Purchasing 
Department. The Purchasing Agents are responsible for the buying practices of 
the company, ensuring that the company is doing business with the most 
appropriate suppliers and ensuring that employees are buying the most 
appropriate items. 

It is desirable to get the Purchasing I>q)artment out of the loop of the 
requisitioning process. However, it is also desirable for them to retam control 
over the process. The system balances those desires by involving the Purchasing 
Dq)artment only when there something unusual about a particular requisition. 
For exan:q)le, a Purchasing Agent will typically be involved when someone tries 
to buy an item from an unapproved supplier or when someone specifies an 
unusual ship-to address. 

The Purchasing Dqiartment, via Admmistrative Tools software 506 
(Fig. 5), defines which products and suppliers are "approved". The Purchasing 
Dqjartment also implicitly and explicitly manages the Product Information 
Database, which describes the collection of approved products and services. The 
Administrative Tools software 506 provides Purchasing Agents wifli the ability to 
add or remove items from the Product Information Database, or remove items 
when a relationship with a suppli^ changes or an item is otherwise obsolete. 
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Another piece of the user environment 500 of the system is Reports and 
Graphs software 508 (Fig. 5), which allows a compBity to summarize, group, and 
understand its purchasing history. TTie system preferably provides software to 
generate one colleaion of predefined rqx)rts that can be run at any time, giving 
purchasing agents and system administrators information they can, use to refine 
their buying process and maximize die gain from automation. This information 
can be a valuable tool for gaining understanding and using that understandmg to 
make improvements, such as modifying the approval processes or switchmg 
suppliers or updating the history of purchases to encourage different buying 
patterns by end-users in the future. 

The system environment 404 is the "back-end", the parts of the system 
that do not directly interact with the users. 

Flexibility and configurability are important to the design, because each 
company wants to maintain slightly different data and enforce slightly different 
business rules. To support die goal of flexibility, one embodiment of die system 
is designed to allow companies to customize the set of data fields, recognizing 
that every company has a slighUy different set of information that must be kept. 

These "extensible fields" are defined by die customer, on a system-wide 
configuration file, and are available both via user interface software and 
throughout the business rules. There are exanq)les diroughout tfiis patent 
application of how such fields can be used. For example, a company might wish 
to extend die set of data fields to describe its own accounting policies and 
categories. 

Approval rules are the conditions that a company uses to decide which 
approvers are required for a particular requisition. The system preferably 
provides a mechanism for describing die a?>proval rules diat is flexible enough to 
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model the existing process at any company. Every company will have its own 
set of rules, although there are often basic similarities, and many rules can be 
copied from simple examples. For example, an approval rule may be expressed 
as a set of conditional expressions, such as "If the amount of this purdiase is 
over $25,000 and it is for software, then the Information Systems department 
must approve the purchase. " 

There are at least two things to note about the approval rules. Fkst, 
approval rules can be based on any field in a requisition, including the fields that 
are added during the implementation process. So, in addition to standard 
approvals based on requisition or line item amounts, for example, the Facilities 
Manager might need to approve any furniture purchase, or the IS dq)artment 
might have to approve any computer system purchase. 

In addition, an approver designation does not have to be given to a 
particular individual in the company. Rather, a particular role can be designated 
in an approval rule as an approver. An example role is the "CFO" role. At any 
given time, this role is played by a single individual in the company, but if there 
is a new CFO hired, then all the requisitions that are awaiting approval by the 
CFO can be approved by the new CFO when he comes on board, without any 
system maintenance. When the individual who is the new CFO is designated in 
the system as CFO, he will be notified of all requisitions pending 2q>proval for 
the CFO role. 

Roles can also describe a group of people. For example, there is the 
role of Purchasmg Agem. There mi^t be any number of Purchasing Agents in 
the company, but if the role Pundiasing Agent is assigned to a requisition, then 
all individuals designated by the Purchasing Agent role see it for their approval. 
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In one embodiment^ if any one of tfiem approves it, the requisition is q)proved 
for that role. 

Adapters 122 (Fig. 1) and 800 (Fig. 8) are software modules that link 
the system to the rest o^ the enterprise. The system obtains and stores all data 
through an adapter layer that integrates the system with existing services, using 
data that already exists in those legacy systems. This assists in avoiding 
duplication of information within the enterprise. If an adapter for particular data 
does not exist, then the system will store the information internally, but if the 
data exists elsewhere in the enterprise, then the system will use the data through 
an adapter. 

Significant adapters are adapters 804 to die ERP system m die company. 
These ads^ters may be customized to int^iiace with each ERP (e.g. Oracle 10.4, 
10.5, 10.6, SAP, Baan, D&B, PeopleSoft, etc.). The ERP ad^ters can obtain 
simple information from die ERP like units of measure, accounting information, 
etc., as well as item templates, supplier information, 2q)proval matrices, and other 
relatively static information. They are also capable of storing the entire approved 
requisitions back into the ERP. 

Another source of information in a company is the description of all of 
its employees, hicluding names, organization information, contact information, 
and so on. Often this information comes fix)m an HRMS system. In one 
embodiment, an HRMS adapter 806 (e.g., to Peoplesoft, Vision 5.0) is 
provided. 

There are also adapts 808 for user authentication systems. User 
audientication information is commonly stored in external directory services like 
LDAP. Miorosoft Exchange, or Una NTS, 
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Now that an embodiment of the system has been broadly described in 
overview, portions of the embodiment are now described in greater detail. 

User Environment 

This section describes the pieces of the system that employees see: the 
user interfaces and associated help and wizard systems. 

When reading this section, the extensible fields design should be k^t in 
mind. That is, each instantiation of the system can have a slightly different user 
interface, customized to present the infOTnation appropriate for that particular 
company. This document contains a number of tables describing data fields. 
Each table differentiates two kinds of fields: 

■ An intrinsic field is a field that the system expects to find. 

■ An extrinsic field is an additional custom field, typically added 
during installation. There can be any number of extrinsic fields, depending on 
what a particular company desires. The system will store and display the 
information in these fields, but in a preferred embodiment, will not depend on 
having the information there. TTiis document contains a number of examples of 
extrinsic fields, to illustrate how they can be used. 

Requisitions 

This section deso-ibes the basic fiinctionality of the system: how 
employees go about asking for something by (seating a requisition. 
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i> Starting Ne w Requisitions 

The user interface for creating requisitions should be appropriate for 
both novice users - people who may use the system only once or twice a year — 
and expert users, who may use the system almost daily. 
5 The system allows users to create new requisitions in at least the 

following ways: 

a. With the requisition Wizard, which guides the employee dirough 
a series of questions at each step, providing navigational aids to keep o^k of the 
big picture, and presenting lists of choices whenever possible instead of asking 

10 the employee to type things in. 

b. By cloning existing requisitions. 

2. Filling in Requisitions 

A requisition can contain any number of individual line items that the 
15 employee would like to order. In one embodiment, there are some parts of a 

requisition that are shared among all line items, and others that are specific to 
individual line items. To initialize the information that ^plies to the entire 
requisition, the system will: 

a. Fill in fields of the requisition from the employee's personal 
20 profile, as available. For example, the shipping information and default 

department will be initialized from the personal profile. The employee will be 
able to change any of these defaults for a particular requisition. 

b. Generate unique alpha-numeric identifi^ for each requisition. 
The format of the numbers can include a prefix string, defined as part of the 

25 con4>any configuration. 
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c. Allow the employee to give titles to requisitions, more 
mnemonic than the requisition tdeiitifier. 

d. Provide a way for one employee to prq^are a requisition and 
submit it for someone else. That is, allow the creator and submitter to be 
different people. If the requester and the submitter are different^ then the 
standard approval rules will put the requester as the first 2q)prover. 

e. Allow the employee to specify a hold date on a requisition. The 
hold date is the date that the employee would like the requisition to be actually 
submitted to Purchasing. If the requisition is fully approved before the hold date, 
then the system will hold the requisition until the hold date. If there is no hold 
date, then the system will submit the requisition as soon as it is fully proved. 
In one embodiment, holding is a company-wide feature, and can be turned off in 
the system profile for an entire company, if that company does not choose to 
allow the hold functionality. 

f- Allow the employee to specify the reporting currency of a 
requisition and display the total for the requisition in that currency. TTie 
reporting currency of a requisition defaults from the employee's default reporting 
currency. The system will display each currency with the appropriate precision. 

g. Timestamp each requisition with the time the employee initiated 
the requisition. 

Table 1, below, sununarizes the fields of a requisition record. 


Table 1; Fields of Requisition 


I Field Name 

DescfiptioB 

Intrinsic? 

1 1. Number 

Unique ID far rcqtufitkm t« iMci^n^ ^ 
prefix sning defined in the system profile. 

Intxinsxc 

2. State 

{Unsobmitted, Sofamined. Folly Af^noved} 

Intxinsic 

3. Requesu:r 

Name of pexson who solmiitted die icqmaticm 

Iiniinsic 
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1 Held Name 

Descripdon 

Intrinsic? 


Name of person v/bo prepared the retjtnsidon. 

Intrinsic 

5. TiUc 

Name chosen by the employee 

Intrinsic 

6. Creation Date 

Date and time on v/faich the reqoisidon was generated; 
the New requisinon time. 

Intrinsic 

7. Submitted date 

Date and time on which the requisidon was submitted; 
the Submit time. . . 

Intrinsic 

8. Approved Date 

Date and time on v/tdch the requisidon was fully 
approved. 

Intrinsic 

9. Hold-till Date 

Date on which the employee would like the requisition 
released to mifcfaajdnff 

Intrinsic 

10. Ship-to 

De&ult ship-to address. Can be overridden for individual 
line items. 

Intrinsic 

11. Reponiiig currency 

De&ult currency for displaying totals and for ad-hoc 
items diat the user crbates. 

littrinsic 

12. Line items 

Individual items being ordered. See the table below. 

Intrinsic 

13. Department 

Used ^ thg dc&nlt for newlv-cTMfMf line ttRmc ti/hf/4t 
can be ovetiidden for individual line items. iwiriaifTH to 
die requester's department, but die requester may wi^ to 
ovenide that initializarion and provide a different defoult. 

Extrinsic 

14. Deliver-to 

Used for internal distribadon« in companies with no 
desktop receipt c^>ability. 

Extrinsic 

15. Total Cost 

Total cost calculated from Price Extended 

Derived 


Extensible fields, custom to diis coaq>any. 



3. Adding Line Itemq 

After creating a requisition, the employee can add any number of 
products and services to it, as line items of the requisition. The system guides 
employees toward dioosing items from ^proved sources, rather than asking them 
to type in information manually: the interface eiiq>hasizes cc^ying and selecting 
and deeixq>hasizes typing. 

The system provides the following ways for an employee to create a line 
item in a requisition: 
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a. By searching or browsing trough a Product Information 
Database. The Product Information Database for a company is the collection of 
all items that have been approved for purchase. 

The user may navigate the tree hierarchically, say by navigating through 
choices Wee Office Supplies, Computer Peripherals, Industrial Equipment, etc. 
and then from Computer Peripherals through Network Adapter, Disk Drive, 
Monitor, etc. 

TTie user is also able to search the Product Information Database with a 
"contains" search on the following fields: Item Description, Supplier Part Id, 
Mfg. Part Id, Mfg. Name, and Commodity Code. 

b. By choosing from a list of personal favorites. In one 
embodiment, a Favorites list is a "flat" list of up to 25 items that the employee 
has chosen and marked as Favorites. 

c. By manual entry, typing in or using the copy function to order 
an item that is not avaOable either from the Product Information Database or 
from any Web catalog. When entwing an item from scratch, the requester can 
suggest a supplier (by selecting suppli^ from a quiciq}ick list or by directly 
typing it in), or leave it out^ to be chosen by the Purchasing Agent. Requisitions 
for items that are not from £q)proved sources typically trigger special approval 
rules, such as requiring a Purdiasing Agent to approve the new item and 
supplier. The system provides facility for each company to define its own rules 
for handling such requests. 
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4. Filiinp in Line Items 

After adding a line item, the employee is able to modify any of the 
information about that line item, as appropriate. Quickpicks are provided for all 
fields to maximize accuracy. In panicular^ the employee is able to: 

a. Specify the quantity to be ordered 

b. Specify the ship-to and deliver-to addresses. 

c. Modify the carrier or carrier method, if the defaults from the 
supplier are not appropriate. For example, the employee might want to ask for 
something to be shipped faster than the supplier's usual practice. 

d. Specify a need-by date, to inform the supplier of the date by 
which the item needs to arrive in order to be useful. 

The fields of a line item in a requisition record, in one embodiment, are 
described below in Table 2. 


Table 2: Fields of a line tton 


1 Held Name 

Description 

intrinsic? 

I. Product Infonnatioii 

inforaiation taken from the Product Information 
Database, vMch includes all infoimation that the user 
cannot chantge: si^plier, price, commodity code, tmit 
of measure, etc. 

Intrinsic 

2. Quandty 

Qoantity of the item to be porcfaased 

Iimindc 

3. Ship-to 

Ship-to address for this Hne item. De&\ilt5 to that of 
tttt entire reqtd^tion. 

Intrinac 

4. Deliver-to 

Deliver-to address for this line item. De&olts to that 
of dtt entire icqnisirion. 

Inninsic 

S. Carrier 

For shqiping item. "FedEx* or "UPS", eg. Defeults 
from item tfmplntr for this item. 

Ittfrifisig 

6. Carrier Method 

E.G. "second day air" 

Inninsic 

7. Need-by date 

Emetcd by employee, to describe the date that be or 
she needs die item to arrive. 

lntfinctc 

8. Accoundng Infonnadon 

Accouudi^ infonnadon, such as department, projea, 
cost center, and account code. 

Exoinsic 

9. Price Extended 

Calailatcd from Quantity X Price. 



Extensible fields, custom to thic company. 

Derived | 
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5. Comments and attachments 

Any employee vAio handles a requisition, be it requester or approver, 
can add commentary or attach documents to the requisition, helping everyone 
who sees it to bettw understand the requisition. The ability to comment and 
explain can go a long way toward making requisitions unda^tandable to 
approvers, allowing them to provide feedback to requesters, and help them make 
a decision about whether to approve the request. 

Hie commenting mechanism: 

a. Allows users to add textual comments to any requisition or line 
item, using "threading* to maintain context. 

b. Allows users to specify the audience for a comment, which can 
be any of Approvers, Requesters, Suppliers, Purthasing, or All, Comments are 
visible only to the specified audience. 

c. Allows users to attach electronic documents to comments. To 
ensure platform indq)endence, tiiis feature is preferably implemented using a 
browser's mailing facility. If employees can send attachments from their mailer, 
then they can attach documents to a requisition. 

6. Submitting Completed Requisitions 

When an employee has finished filling out a requisition and asked to 
submit it, the system will p^orm the following checks before actually submitting 
the requisition for approval: 

a. Find all mandatory fields (as distinguished from cq)tional ones), 
and ensure that they have values. If there are any missing values, then the 
requisition is returned to tfie us^ for more editing. 
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b. For each field that has a value, verify the data in that field to 
ensure that values are valid for the field involved as well as validating that the 
account combinations (e.g. Account, department, etc.) are valid. If there are 
validation procedures for any of die extrinsic fields (custom to this company), 
then run those validation procedures as well. If there are any invalid fields, then 
return the requisition to the user for more editmg. 

c. Check each line item and assign a suggested buyer for that line 
item. The company can parameterize the rules for assigning buyers to line items, 
based on any fields in the requisition. If there is a direct order agreement with 
this supplier, the suggested buyer will be the buyer agreed on in the supplier 
profile. (TTie supplier profile specifies whether there is a direct order agreement 
in effect.) 

d. Add bill-to information, using default from system profile. 

e. Timestan^) the requisition with the current date and time, as the 
submission date of the requisition. 

f. Determme the approval path for this requisition, using the 
approval rules defined in the business rules for the company, and allow the 
employee to preview the approval path. Allow the employee to eithw- confirm 
the submission, or cancel it and return to editing the requisition. 

The Orp anizftf 

The user interface software for categorizing and classifying requisitions 
is known as the Organizer 504 (Figure 5). Approvers use the Organizer software 
to approve or deny requisitions and requests use it to dieck status and history. 

When a request is submitted, the system diecks die ^proval rules of the 
company, decides whidi users need to approve the request, and in what order. 
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and then notifies the first approve that there is a requisition waiting for attention. 
Each approver sees new requisitions in a fold^ of incoming requisitions, and will 
need to take action on the requisition to move it to a different folder. 

1. A pproving or Denying Requisitions 
When an approver goes to the Organizer interface, be it from a 
notification message, a bookmark, or some other hyperlink, the Organizer 
displays the incoming requisitions for that approver, showing the information in 
Table 3, below, for each requisition: 


Table 

3: Fields of an approval request 

1 Held 

Explanation 

1. Role 

Role required for this approval, siKfa as *CFO'. 

2. Reason 

The reason this ^ipiover needs to ^)prove; dus is the 
justification field 

3. Acaia] Approver 

The name of the person who is fiUing the q)proval role. 
This is typically the ^ravex*s name, if the approver is 
looking at incoming requisitions. 

4. Required/Opdonal 

Boolean indicadng vliether this sppiavH is required, or 
whether this approver is a "watdier". 

5. Submission Date 

The ^bmission timestanq). 


AVhenever an approver acts on a requisition, the system timestanq)s the 
requisition with the name of the approver and the time of the action. 

If an approval is marked as requked, the approver can take any of the 
following actiom on the requisition: 

a. Approve the requisition. An approval will triggw any 
notifications specified in the business rules for this company, mark the request as 
approved for this approver* and add the request to the mcoming foldw for the 
next approver in the approval chain. After approving a request, the approve* can 
move it mto some other fold^, or leave it in the incoming fbldo-. 
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b. Deny the requisition. When an ^prover denies a requisition, 
the system sends an e-mail notification to the requester, and stq>s any further 
approval requests in this serial approval chain. If the requester does nothing in 
response to a notification of denial, the request will eventually time out. If the 
requester modifies the request and resubmits it, the system starts the approval 
process again, as described in step 5) below. 

c. Add an additional approver to the ^proval chain, either before 
or after this approval. For example, an approver might want to say "Please ask 
Ed if he 2^>proves, and then come back to me". 

d. Add comments. 

e. Modify the requisition. Not all approvers can change all fields, 
however: a Purchasing Agent can modify any field of a requisition; other 
approvers can modify only a limited set of fields in the requisition. The 
definition of which fields approvers can modify is part of the company's 
configuration of the data fields and is typically set up during installation. 

When an approver modifies any field of a requisition, the system 
recalculates the required 24)provals and invalidates any existing approvals for that 
line item (if it was a line item that changed) or for the entire requisition (if the 
requisition itself was changed). Modifying a field can thus trigger re^provals 
from users who have already approved the requisition, or trigger the addition of 
new approvers into the chain, dq)ending on the q>proval rules. 

If the ^prover is marked as Optional, then this approver is a watcher^ 
not a true approver. Watchers are bystand^: diey see the requisition but their 
approval is not required. Watcha^ can take any of the following actions on the 
requisition: 
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■ Add an additibml approver to the approval chain, either before 
or after this approval. 

■ Add comments. 

2, Approving in the place of others - " 

The system maintains the notion of chain of command dmved from the 
"immediate supervisor" information in each employee's pw^nal profile. Using 
that information, the system allows certain authorized approvers to zppiove in the 
place of another approver: 

a. The system allows approves to get a list of the requisitions that 
are waiting for ^proval from a lower-level approve- (as defined by the business 
rules) and approve them directly. A high-level approver can explicitly ^prove in 
the place of any lower-level ^prover if the two approvers are in the same chain 
of command. 

■ /. 

3. Removing Requisitions or Approvals 

a. A requests can withdraw his or her own requisitions at any 
point during the q)proval process, until the requisition is fiilly approved, A 
withdrawn request returns to the Unsubmitted state and any ^provals that have 
been recorded so far will be removed. 

b. An employee who has die role of Purdiasing Agent can remove 
£4>provaIs from any requisition. 


4. QrpaniT^pp ^ifc^j^^ry^c 

The Organizer helps enq>loyees organize groups of requhitions. 
allows employees to: 
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a. Son the requisitions by any of the fields that are displayed in the 
outline view. That is, if there is a column header for a field, then the employee 
can sort on that field. 

b. Filter the requisitions by any of the fields that are displayed in 
the outline view. That is, if there is a colunm header few: a field,' then the 
employee can use the value of that field to restrict the information being 
displayed. 

c. View the details of any requisition, including all line items, 
approvak, and comments. 

d. Put the results of a search into a folder. For example, a 
purchasing agent might wish to examine all outstanding requisitions for items 
from a particular supplier. 

e. Print any requisition on letter paper. 

f. Fax any requisition, on platforms with integrated fax support. 

Now, administration of the system is described, in the sense of making 
changes that are not part of the server configuration itself. 

L M^ftt^ftifig P^ff^ PlTQfHes 

An employee*s personal profile is described in a configuration file that 
sets values for a user of the system. There are two kinds of information in a 
personal profile: Human Resources data fields and specific data fields. The 
Human Resources data fields are preferably initialized from the HRMS adj^ter, 
if there is one at the site, and are also updated regularly from the HRMS adapter. 
The specific data fields are created and maintained entirely within the system. 

The system: 
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a. Allows employees to view and edit the specified fields of their 
own personal profiles* in a form consistent with the rest of the Ul. 

b. Submits all changes to personal profiles for ^rovals, as 
described in the approval rules of the company. 

c. Allows enq)loyees to view the Human Resources data fields that 
are passed through from the HRMS adapter. 

d. Allows employees to add or remove items from their favorites 

list. 

Table 4, below, lists the specific data fields of a personal profile. 


Table 4: Fields of Personal Profile 


1 Held Name 

Explanation 

Intrinsic? | 

1 I. Origamzadonal Lcvd, Numeric 

Numeric degree of separation from CEO. 

Intrinsic |{ 

2. Delegation of authority (DOA) 

Any employee can designate appiovdl authority to 
another user* for some period of time. 

Intrinsic i 

3. Stan date of DOA 

Stan date for DOA. 

Intrinsic i 

4. Teraunation date of DOA 

Expiration date for DOA. 

Intrinsic 

5. Reason for DOA 

A ccnnment: a textual description of why the 
DOA is in effect. For example, 'vacation*. 

Intrinsic 

6. Notification Frequency 

As they occur, on interval, etc. 

Intrinsic f 

**** 

Extensible fields, custom to this company. 

Extrinsic | 


2. Maintaining the System Profile 

The system profile contains configuration values for an instance of the 
system. The system profile (an example of vdiich is shown in Table 5) is created 
when the system is installed. It is intended primarily for setting default values 
that will be used when creating profiles for new employees. 

The system: 

a. Allows the administrator to change the fields of the system 
profile, using a simple text editor or spreadsheet. 
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Table 5; Fields of a System Profile 


5 


10 


15 


1 . System Name 

Name of the company. 

Intrinsic [ 

2. URL 

URL of borne page for this system 


3. Approval escalation time 

Detolt interval before approval is escalated. 


4. Time-out imerval 

Time span before a requisition times out, if it has been in 
the system with no acdoiL 

iiminsic 

5. Base curTcnc7 

System's standard currency 

Intrinsc 

6. Fiscal Year 

Date on which the fiscal year for this con^xany begins; 
used to calculate dates for reporting purposes. 

intrinsic 

7. Nofiftcatitm frequency 

De&ult that can be overridden by employees. 


8. No notilftcatton okay? 

Boolean indicatipg whether enq>loyees can turn off 
notifications. 

intrinsic 

9. Hold dates okay? 

Bocrfean indicating whether enq)loyees can specify hold 
dates on requisidons. 

Intrinsic 

10. De&uh ship-to address 

Defiuilt diat can be overridden by employees. 

Intrinnc 

1 1 . De&ult bill*co address 

Dc&ult for diis company 


12. Requisition nuomber 
prefix string 

Prefix used when immberiog requisidons. 

Intrinsic 

1 13. Diiea Order number 
J prefix stririg 

Prefix used when numbering direct orders 

Intrinsic 

3 14. **♦♦ 

Extensible fields 

1 


3* Maintaining the Product Information Dataha^a 
20 The Product Infonnation Database of a company is the collection of 

item templates for items that are approved for purchase inside the company. 
Item templates are maintained entirely on the system. An example item template 
is illustrated in Table 6. The Purchasing Department of a company is typically 
responsible for mainiaimng the Product Infonnation Database, helping to make it 
25 an accurate and valuable resource. 

The system allows purchasing agents to create, edit, and remove 
item templates. This functionality is available only to purchasing agents. It 
allows them to: 
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a. Create new hem templates. The need to create new item 
templates arises most often when there is a requisition for an item that is not in 
the Product Information Database. If die Purchasing Agent decides to approve 
the item, he or she will create a new item template for it and decide whether to 
add it 10 the Product Information Database. 

b. Edit existing item templates. A purchasing agent can modify an 
existing item template, (e.g., update supplier information or price). 

c. Remove existing item templates. A purchasing agent can 
deactivate an item from the Product Information Database, if the purchasing 
agent decides diat the item is invalid or no longer recommended. This can 
happen for any number of reasons, such as when the relationship with a supplier 
changes or when a particular item is no longer available from the supplier. 
When a purchasing agent makes such a change, he or she can use the Organizer 
view to check all outstanding requisitions to see if there are any that are impacted 
by the change. 

d. Read in text files from suppliers, with SIC code. [WHAT IS 
SIC?J map those SIC codes into internal commodity codes, and then add die 
relevant items into the Product Information Database. 

e. Build and maintain a hierarchical view of the Product 
Information Database, so users can find diings navigating about dirough 
categories. 


Tabled; ItoaTmipIate 


1 1. Item Number 

Nmnber diat umqoely idcmifies the item. Defined by the 
system. 


2. Item Type 


Key diat assigns die item to a groop of items (e.g., office 
si^plies). 

limiiBiic 1 

3. Commodity Code 

Commodity code of the item. Commodity codes are per- 
company. 

IntiiQsic 1 
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B i. iicm nuiuDcr 

Number that uniquely identifies the item. Defined by the 
system. 



Intrinsic 1 

R 4. Desktop Receipc ? 

Whether the item is eligible for desktop receipt. 

Intrinsic 

5. Delivery lead time, in Days 

Number of days needed to procure die item when it is 
purchased externally. Need a value for "unknown.* 

Intrinsic 

6. Supplier ID 

Unique ID for the siqyplier of this item 

Intrinsic 

7. Company Unit Price 

Puidiase price* per unit, in this ccsapany- 

Intrinsic 

8. Siq>plier URL 

URL for additional information. 

Intrinsic 

9. Maxnifacturer URL 

URL for additional information 

Intrinsic 

10. Carrier 

Prefened carrier for diis item 

Intrinsic 

11. Carrier mediod 

Preferred method for this item 

Intrinsic 

12. Transfer Method 

{ERP, Direct Order, None} Dominates over supplier 
designated transfer method 

Intrinsic 

13. Supplier 

Link to the supplier. 

Intrinsic 

14. UOM 

Unit of measure for item 

ExtriiEdc 

IS. Item Description 

Textual description of the item 

Extrinsic 

16. SIC code 

Standardized code for the item. 

Extrinsic 

17. List unit price 

Purchase price, per unit, set by supplier 

Extrinsic 

18. Buyer 

Role responsible for buyir^ the part; itqmt to die ^>proval 
rules 

Extrinsic 


Boolean indicariT^ \^iether item is taxable 

Extrinsic 

20. Supplier Pan Number 

ID for diis item, from the surlier 

Exorinsic 

21. Manu&cturer pan number 

Id from manu&ctnrer 

Extriiisic 

22. Manufiicturtr name 

Name of marnifacturer 

Extrinsic | 

**** 

Extensible fields 



The system provides a rq)oitiiig £Eu:iIity to help buying companies 
summarize, analyze, understand, and improve their buying process. The system 
comes with a number of pre-defined rq>orts, ranging from buying pattens (e.g., 
are we buying too much of something or too litde?), to reports on die process 
itself (e.g., who is not approving in a timely manner). This information can help 
tiie conq)any refuK its practices, say by modifying the q)provaI processes or 
switching suppliers. 
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1. Defining Rqiorts 

The system provides a variety of reports to categorize and group the 
information contained in the system. The reporting mechanism allows en^>loyees 
to parameterize reports and run them, but not to define ad-hoc reports. 
Employees are able to: 

a. Save die results of any generated rcpon to a file. Thwe are two 
output formats: one that can be read by spreadsheets, and one that is plain text, 
for human consumption. 

b. Print any of the generated rq)orts. 

c. Define the rqK)rting period for any rqwrt. TTie period of a 
report can be described as {All, TTiis DayAVeek/Month/Year/Quarter, Last 
DayAVeek/Month/Year/Quart^, Other (where a specific beginning and ending 
date can be specified)}. The definition of Quarter is set from the system profile. 

2. Standard Reoorts for Air Employees 

Table 7, below, shows standard reports that are available to all 
employees. 

- Table 7; Standard reports for aU employees 


Report Name 

Pri<xity 

1. ReqnisitibDS for spedfied pcdod 

lOfigh) 

2. Summaiy of q^proved ontes fox a period 

KHigh) 

3. Reqaisidons sdU to be Bpjpimed, by whom 

l(Hi£^) 

4. Line items by siqsplier 

Ifffigh) 

1 5. Line items by ^^nover 

ICHigh) 

1 6. Average of fines 

l(HigJi) 1 

7. ReqoiadoDs by commodity 

2 (Medimn) I 

8. Average time to approve 

2(Medram) | 

9. Requisidoiis denied, grouped by whom 

3 (Low) 1 
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3* Standard ReT>ons available to purchas ing ag ents 
Provide the standard reports as shown in Table 8, available to any 
employee who has the role of purchasing agent: 


Table 8; Standard Reports for Purchasing Agents 


Report 

Explanation 

Priority 

I . Upen oraer roIlow-iq> 
repon 


1 (High) 

2. On-ume delivery rqx)rt 
by supplier 

Need limited set of buckets, such as "on-time*, 
•# of days cariy". of dates late", etc. 

1 (High) 

3. $ or iicms by supplier, 
in alpha order 

Output to ^readsheet for gr^hics 

1 (High) 

4. 0 of vansacuons per 
employee, supplier, depi, 
div 

Output to spreadsheet for gra}^cs 

I (High) 

5. Summary Rqx>n 

Supplier, Item, dept, date ordered, date recdved. 
Requester, Expected delivery 

1 (High) 

6. Order list for a supplier 
to date 

Only sununaiizes total of PO 

l(HigJi) 

7. Total orders to 
suppliers 


2 (Medium) 

8. Suppliers, 
alphabetically 

Brief list of siq>pliers, sorted alphabedcally 

3 (Medium) 

9. Onreceived orders by 
Supplier 


3 (Medium) 

10. Number of 
requisitions initiated by a 
given employee, in some 
period 

Watching for pec^le who consistently order just 
under an s^proval limit 

3 (Low) 

1 1. Paper vs. electronic 

Number of dectronic requests submitted, as 
compared to number of paper ones 

3 (Low) 

12. % of items ordered 
that were ad-hoc 

Traddxig adrhoc items vs. catalog items 

3 (Low) 


System Envirnnmft^i 

Approval Flow 

Each company generally has its own approval process for defining who 
has to approve each requisition. The system models this process with a set of 
approval rules, whidi each conq>any can parameterize and extend. The 2q)proval 
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rules are defined as part of the installation process, but can be modified by the 
customer's system administrator at any time, 

The £^proval rules are preferably stored in text files that can be edited 
with any text file editor. 

1- Parameterizing Approval Rules 

n^e sinq)lest form of approval rules is a tabular file format, which 
describes values to be used in the rules. This file format allows the customer to: 

a. Parameterize the approval rules by editing the values in the 
tabular file. For example, a company can change the dollar amounts to be 
associated with approval by various management levels, without changing the 
approval rule itself. 

b. Change the parameters while the system is running. The system 
will read in new parameters without downtime. 


2. Approval Rules 

For describing the ^proval rules, the system provides a sinq)le Scripting 
language, gei^ally flexible enough to desaibe any condition or set of conditions 
file approval. In one embodiment, eadi rule has: 

a. A justification field, to be used as e5q)lanation for why the rule 
was invoked. 

b, A predicate, whidi determines when the rule ^plies. The 
predicate can be based on any field in the requisition, sudi as commodity, 
currency, amount of purchase, shq>-to address, or even the customized (i.e., 
extensible) fields that this particular company has added. 
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c. A consequent* for when the predicate applies. The consequent 
designates which role or roles need to approve the requisition. For example, a 
company might write a rule that requires employees with the role of purchasing 
agent to approve any requests that are for amounts over $200 and that have a 
ship-to address that is different from the default ship-to address* The particular 
amount, the $200, will be specified in the tabular file; die predicate-consequent 
will be in the rules file. 

d. A way to desoribe whidi ^provals can be done serially, and 
which can be done in paralleL For example, an organization may want the 
management cham ^provals to go sa-ially, but other approvals Oike Facilities 
and IS) to go in parallel. 


3. Buver Assignment Rules 

Each line item in a requisition has an assigned Purchasing Agent. The 
system sets the assigned Purchasing Agent before submitting the request for 
approval. Each company can define its own rules for how buyers are assigned, 
using the same mechanism used for defining approval rules. For example, a 
company might wish to have the assignment of buyer be dqjendent bodi on the 
type of the commodity and the amount of the purchase. 

4. Escalation and Timing Out 

The system provides the ability to escalate an approval, either manually 
or automatically, for occasions when an approver has not responded to a request 
for approval. Escalating an q)proval request moves it up the management diain, 
to the ^prover's inunediate sup^isor. 

The system provides the following features for escalation: 
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a. A requester can escalate a request manually* 

b. If an approver has not responded to a request for approval 
within the escalation time period defined in the system profile, the system will 
escalate die approval request automatically. Escalation will continue up the chain 
as necessary, until someone takes action or there is an employee with no 
supervisor, 

c. If a requisition has not been approved within some time period, 
as specified in the system profile, the requisition will time out. That is, any 
request that has been submitted but not yet fully approved within the specified 
time frame will be escalated to the administrator. 

d. Once an approval request has been escalated, the original 
designated ^prover can no longer take action on that request. 

5, Delegation of Authoritv 

Delegation of authority (DOA) is a substitution of one ^prover for 
another in a specified time period, say when an approver is on vacation. In one 
embodiment, the system si^ports delegation of authority in the following ways: 

a: Any employee can delegate his or htr authority to anoth^ 
employee for some period of time. DOA includes a start date, end date, and 
comment field explaming why the DOA is in effect. The DOA is stored in the 
employee*s personal profile: like all changes to personal profiles, delegations of 
authority are subjea to the approval rules of the company. An employee cannot 
delegate to more than one person at a time, or split the DOA among more than 
one designee. 


wo 98/49644 PCTAJS98/I»407 

-34. 

b. If xbtre is a delegation of authority for an employee, and the 
date for the delegation has not expired, then the system will allow the delegate to 
approve in the place of the employee. 

c. Log all delegations of authority as part of the audit trail. 

Shared Services 

1. Authentication and User Rights 

All employees must log in and be authenticated in order to use the 
system. There are three kinds of users in the system: Purdiasing Agents, 
Administrators, and Employees. Purchasing Agents and Administrators are 
allowed to do some operations that Employees are not allowed to do. Table 9, 
below, lists the operations that are restricted to certain kinds of us^: 


Table 9; User Rights Requiring Aothendcation 


Role 

Functionality || 

I. System Adminiscrator 

■ Designate other employees as administiators or purchasing agents 

■ Load new business lules into the server 

2. Purchasing Agent 

■ Remove qyprovals fsam xcquidtioQS 

■ Edit any field of a lequisition 

■ Modify fbt Product Infoxmadon Database 

■ Modify die specific fields of die supplier database 


2. Pyctb affd NoMfigatiPn 

The system provides a notification medianism, designed to help keep all 
int^ested parties mformed about what*s going on with a particular requisition. 
The system defines a set of events^ which are the triggers for notifying 
employees, and the recq)ients of the notifications. In one embodunent, there is 
no customization of the set of events. 

The system will: 
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a. Provide e-mail notification for each of the defined events, which 
are summarized in Table 10, below. The notification message pref^^Iy 
includes a hypertext link to the Organizer. 

hr Allow employees to customize the frequency of notification per 
event. TTie notification frequency can be specified as Never, Immediate, or On 
Interval, where the interval is an integer number of Seconds, Minutes, Houis, 
or Days. The decision of whether to allow employees to specify Never is 
preferably part of the system profile - that is, choosing whether it is possible to 
turn off notification altogeth^ is a decision made on a p^-company basis. 


Table 10; Events Requiring Notification 


Event 

Action 

1. Approval is now required 

Nodfy activated approver. 

2. An approver takes action: aj^roves or denies. 

Notify requester. 

3. New ^rover or watchex added 

Nodfy requester. 

4. Requisition has been mo^fied 

Notify requester. 

5. Rnal receipt submitted 

Notify Puichasing. 

6. PQ# Assigned to Requisition Line Item 

Notify Requester. 

7. Time expired for delivery: if die Need-by date 
passes and no receipt acknowledgment has been sent. 

Notify requester diat a receipt is 
required. 

8. Requisition has been escalated to next-level 
approver. 

Notify current approver and 
activated appiovei aixl 
requester. 

9. Requisition is soon to be gggahtM 

Notify appro vet. 

10. Requisition is soon to rime out 

Notify requester. 

11. Requisidon has timed out 

Notify requester. 


3. Database Support 

The system uses a database to store all int^nal data, and record ail 
transactions between clients and die Enterprise Server. In one embodiment, this 
database resides on an Oracle Database Server. 
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4. Customer support and feedback 

There is an interest in feedback from customer sites to understand how 
customers are using the system and how they would like to use the system. To 
encourage such feedback, the system: 

a. Provides a simple feedback command, to allow customers to 
e-mail suggestions. 

b. Provides a support newsgroup or Website, 

c. Sends s^ious system errors as they occur. 

d. Sends line items count statistics on a monthly basis, via email at 
the end of each month. 

5. E-Mail Integration 

Tlie system integrates with e-mail programs already in place (e.g., 
SMTP), so the system can send employees notifications via e-mail. 

Business Modules 

The Business modules are sq)arable pieces of the system. 

Ordering Modules 

An ordering module is the piece of the system that takes a fiilly 
^proved requisition and submits it for fulfillment. When a requisition has been 
fully £^proved, the system will: 

■ Timestanq) it with the date and time of the final approval 

■ Check the requisition to determine which suppliers are involved, 
and choose a supplier site if thwre is more than one site for the specified supplier 


wo 98/49644 PCTAJS9S/08407 

- 37 - 

■ Choose the preferred ordering module for each of those 
suppliers and use it to transmit the order. 

The three ordering modules are a Purchasing Card Module, Direct 
Order Module, and a Purchase Order module. 

I- Purchasing Card Module 

The Purchasing Card ordering module supports the use of purchasing 
cards as a payment mechanism. Purchasing cards (p-cards) can be associated 
with particular employees or suppliers, but are maintained by an administrator, 
who ensures that the cards are valid and are being used apprcq)riately. 
Purchasing card uansactions are reconciled on some regular basis with the bank 
that issued the purchasing card. 

The system maintains the following data associated with each purchasing 
card, as shown below in Table 11. 


Table 11; Data associated witfa a purchasing card 


Card Held 

Explanation 

Intrinsic 

Card number 

ID of card. Assigned by 
administrator. 

Intrinsic 

Employee It> 

The enq)]oyee*s ID 

Intrinsic 

Accoundng Codes 

Prom dte personal profile 

Intrinsic 

Expiration date of card 

The last day ifais card can be used 
in a transaction 

Intrinsc 

1 Authorization limits (Single 

2 Transaction^ 

Ahstdute limit for a single 
purchase with diis card. 

Imrifijrir 




Cardholder name 

Can be diflerem from user name; 
must appear exactly as it does on 
card. 

Extrinac 

1 Bank Name 

Name of issuing bank on dte card 


1 BankiSF 

ID number of die issuii^ bank 
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The purchasing card module: 

a. Allows administrators to assign cards to employees and modify 
the expiration date or authorization limits on purchasing cards. 

b. For each fully approved requisition, verifies whether a p-card 
can be used for this purchase: 

■ Ensure that the supplier accepts p-cards. If not, chooses a 
different ordering module. 

■ Chooses a p-card number: If the supplier has a ghosted p-card 
number, then that is the preferred p-card number. Othwivise, if the employee 
has a p-card number, uses it Otherwise, chooses another ordering module. 

■ Chedcs the amount of the purchase. If it exceeds the per- 
transaction limit on the purchasing card, then chooses some 
other ord^ing module. 

c. For each transaction using a purchasing card, the system records 
data as shown in Table 12. The data is reconciled with banks on a monthly 
basis, using a printed report of the transactions. The reports used for 
reconciliation show an "allowed variance," because the values (i.e., the p-card 
order total) do not include tax and shq)ping, but the bank values do. 


20 

1 Field 



Transaction Date 



P-Card Older # 

This is die ID (vAdch has co be asagncd) of die transacdon, wiudi is used to 
ideadfy d>e transacdon In cxmnnmricadons between die supplier and die system. 


P-Card Qnter Tocal $ 

Calculated sum of line items in order. Pnmed as a range, widun aUowed 
variance. 

25 

Supplier CX: Merchant 
Nmnbo: 

IDof siqyplier. Used for reconciliadon. 
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When a company purchases this module, there are additional standard 


reports available. Reports as described below in Tables 13 and 14 are provided. 
- Table 13: Reports for Ejnployees 


Report Name 

Priority 

Stacemens of Account for the Employee for the Credit card period. 
Lists each transaction. 

1 (Hi^) 

Table 14: Reports for Purchasing 

Report Name 

Pnonty 

Mondily P-Card Transaction Statistics. This report is intended to be 
used for manual recondliadon at the bank. 

1 (High) 

Transaction Audit lisdng (Grouped by cardholder) 

1 (High) 

General Transacdon Lisdng by organization and card holder 
(For Recondliadon) 

1 (High) 


L Direct Orders mO\) 

The direa wder module is an ordering module that supports 
communication of orders directly between the buyer and supplier, without storing 
the requisition in an ERP system. There are typically no constraints on orders 
under direct billmg agreements. The direa order agreement includes terms and 
conditions, and q>ecifies the frequency of billing. 

If tha-e is a direct order agreement with a supplier, then the system: 
a. Checks that the transfer method has been designated for direct 
order in the item template. If neither the purchase order (PO) or DO order 
module has been designated in die item template then the supplier profile will be 
chedced for the transfer method. If the stqjplier profile indicates direct order, 
then that is the method. Otherwise, it is treated as a PO. 
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b. Transmits the requisition directly to the supplier via fax or 
e-mail, as specified in the supplier profile. All requisitions transmitted to the 
supplier are recorded in the audit trail database. Receiving acknowledgement 
information is maintained only in the system. 

c. Provides a report of transactions from the system to help the 
Purchasing Department reconcile with the master statement from the supplier. 
The frequency of the report will muror the frequency of the report from the 
supplier. 

2. Purchase Orders 

TTie purchase order module is an ordering module whose case results in 
a purchase requisition in the ERP system. The system transmits the requisition to 
the ERP adapter, as an ERP requisition. Once the requisition is in the ERP, the 
Purchasing Agent can manipulate it with standard ERP operations to complete the 
process. For example, the agent typically autocreates a purchase order from the 
requisition, prints it out, an sends it to the supplier for frilfillment. 

Receiving 

After an order is approved and submitted and transferred to the supplier, 
eventually the supplier will ship the item and the requesto- will receive it. When 
an item is received, the requester must acknowledge receiving the item; receq>ts 
are the final acknowledgment to trigg^ payment. 

The system includes a user interface for adcnowledging receq>t, whidi 
allows enq>loyees to record tiiat various items have been received. The receq)ts 
will be stored in the system, and there will be no interaction with the underlying 
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ERP, if there is an ERP present A system level toggle that can be set during 
implementation activates the receiving module. 


1. Acknowledging receipt of an item 
5 The. system provides a simple form (the fields of which are~ shown 

below in Table 15) for the employee to indicate that he or she has physically 
received an item. This receiving interface: 

a. Allows an enq)loyee to acknowledge receipt of an ordered item 
and to record the number of items received, showing the information in the table 

10 below. The employee is able to acknowledge either a single line item or an 

entire requisition. 

b. Allows an employee to reject either an entire requisition or an 
individual line item. When an employee chooses to reject somediing, the system 
will ask for a free-form conmient, describing the nature of the rejection. There 

15 are no partial rejections on quantity, though the employee can convey that 

information in a conmient. 

Table 15; Fields for receipt acknowledgment 


20 


I Field 

Explanation | 

1 1. Date received 

Defeults to current date and time; can be overridden | 
by the enq)loyee | 

1 2. Necd-by-date 

As originaUy set in the reqoisidon 

1 3 Item description 

Link to the line item 


Free fonn comment, for noting problems. Any sort 
of problem wiU cause the item to be routed to a 
puicfaa^ng agent, Co be handled mannaUy. 



If the employee rejects an item, the system notifies Purchasing, and 
records the rejection. 
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ReppirtS 

The rqx)ns shown in Tables 16 and 17 may be added to the core list of 
reports included with the core system. 


Table 16: Reports for Employees 


Report Name 

Priority 

1. Items not yet received, sorted by supplier and due date 

1 (High) 

2. Items Received for a period: sorted by siq)plier 

2 (Med) 

Table 17: Reports for Purchasing 

Report Name 

Priority 

1. items not yet received, sorted by supplier and due date 

1 (Higb) 

2. Items Received for a period: sorted by sillier 

2 (Med) 


System Adapter 

The system preferably uses adapters when possible, thus avoiding 
duplicating any information that is already available. But the system is not 
dependent on the presence of any of these adapters, and can run stand-alone when 
a company does not have a particular service or there is no ad^ter available for 
it. 

Directory Service Adaptepy 

The system preferably uses usemame and password mformation from a 
du^ectory service within the company, if there is sudi a service at the company 
and if the company has the ^propriate ad^ter. If the company has no 
authentication service, the system itself stores the employee name and password 
information, allowing appropriately authorized system administrators to create 
new users. 
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1. LDAP Authentication Adapts 

A directory service adapter to LDAP is provided. LDAP (Lightweight 
Directory Access Protocol) is a protocol that provides a standard method for 
Internet clients/ applications and WWW servers to access directory information 
across the Internet. 

The LDAP adapter: 

a. Uses the LDAP protocol for accessing corporate-wide passwords 
and use those passwords for authenticating employees. 

b. Provides real-time authentication of users, if the customer's 
LDAP server is fest enough to suppon it. 

Human Resource N^anapftm^p t System Adap fprjg 

HRMS systems are used for maintaining employee information such as 
names, mailstops, and organization structure. If there is no HRMS adapter 
available, the system supports basic employee management, storing employee 
data in its own database and allowing appropriately authorized system 
administrators to Add/Delete/Modiiy Employees. 

L PeopleSoft H RMS Adapter 

An HRMS adapter to the PeopleSoft system. Version 5 is provided. 
The PeopleSoft Ad^ter: 

a. Extracts employee information from the Peq^leSoft database on 
a regular basis and update die system with any new employees that have been 
created. When new employee updates arrive, the Systran fills in fields from the 
HRMS when available. Other additional fields are initialized with die default 
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values from their immediate supervisor, or from the system profile if the 
manager is not in the system or cannot be found. 

b. Extracts the fields shown in Table 18 below. 
Table 18: Human Resources Data 


5 


10 


15 


Field Nanie 

Explanation 

Intrinsic? 

1. Employee Number 

Alpha-Numeric ID 

Intrinsic 

2. Employee oame 

l-asi, Rrst, Ml. 


3. E-mail Address 

String 

IntriiKsic 

4. Depanmem 

For accounting purposes 

Intrinsic 

5. Expiration date of employee 

AHow for temnorarv emnlnviVK u/hn ran 

"expire". 

Intrinsic 

6. Immediate Supervisor 

Name of employee's inunediate siq>ervisor. 

Intrinac 

7. Fax mmiber 

Phone # 

Intrinsic 

8. Preferred ship-to address 

Address. Physical address* plus maildrop 
and drcqizone or other coiiq>any-q)ecific info. 

Ixurinsic 

9. Job tide, textual 

Like organization level, but texnial (i.e. 
"DirectOT") 

Extrinsic 

10. Telephone mmiber 

Phone # 

Extrinsic 

11. Manager's e-mail address 

For displaying during approval routing 

Extrinsic 

12. Manager's phone number 

For displaying duriog approval routing 

Extrinsic 


ERP Adapters 

2^ ERP ad^ters are the pieces that integrate the system with an enterprise 

ERP system. The adapters are customized for each ERP (e.g., Oracle 10.4, 
10.5, 10.6, SAP. Baan, D&B, etc.). 

One embodiment of the system provides adapters to Oracle ERP 
versions 10.4, 10.5, and 10.6. 

25 

1. Requisition Adapter 

The requisition zdapxer is die basic piece that integrates with die ERP. 
It pushes ftilly-^proved requisitions into die ERP, whwe diey are converted into 


10 
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Purchase Orders on the ERP system. The adapts can pull back the purchase 

order numbers for those requisitions^ and store the PO numbers as extrinsic data 

fields associated with each line item. 

Tht adapter pushes the following data for each line item: 

Description 
Comments 

Requester name, if the requester exists in the ERP. If 
there is no such user name in the ERP, 
then there will be a standard catch-all 
user. 


Approvals 

Quantity 

Unit Price 

Unit of measure 
15 Sliq>-to and Deliver-to addresses 

Part numbCT 

Part descrq>tion 

Accoimting information 

Shq>ping details — Carrier and carrier method 
20 Supplier 


2, Units of Measure Adapter 

The system pulls the set of Units of Measure from the ERP, and use 

them in the user interface. The system pulls the following data: 

25 Name 

Abbreviation 

Base unit of measure 

Conversion to base unit of measure 

30 3. Accounting information Adapter 

TTie system pulls accounting information from the ERP, with whatever 
accounting details are defined for the company. For exan^)le, the accounting 
fields might be: 

Company name 
35 Conq>any business unit 

Dq>artment 
Account 

Project information 
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4. Commodity Code Adapter 

The system pulls commodity code information from the ERP. The exact 
smicture of the commodity codes depends on the company. For example: 
Commodity name 

Accounting information per commodity 
5- Currency Rate Table Adapter 

The system pulls currency rate tables from the ERP, using the rate 

tables whenever currency conversion is required. The adapter pulls a table of 

currencies and conversion rates for each, pulling the following information: 

Currency name 
CurreiK:y rate 

Date the specified rate is valid 
List of valid currencies 

6. Supplier Pro file Adapter 

The system pulls supplier infommuon from the ERP, on a p^iodic 
basis, and store that supplier information in supplier profiles. This ad2q>ter: 

a. Pulls newly-created suppliers from the ERP, Purchasing Agents 
need to create new supplier profiles when someone requests a new item. That is, 
when a requisition includes an ad-hoc line item, the Purchasing Agent locates an 
^propriate supplier and adds a profile for tiiat supplier in the ERP. The changes 
are then pulled back into the system. 

The supplier profile in the system has the fields shown below m 
Table 19. 


Table 19; Siq>plier Profile Data 


FkldName 

Explanation 


1. Supplier ID # 

A^pba-Nomcric ID 


2. Sopplier Name 

Textual name of &e supfdier 



3. E-mail 

Sai^)iier*s e-mail address 

Imnnac | 
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5 


15 


Fldd Name 


Intrimic*^ 

4. Site codes 

Eadi sillier can have multiple sites: each 
siic couc nas an assocsaiea aoctiess. 

Intrinsic 

5. Dispatch method 

Piefeiied method of cransmitdng inforaiation 

lU UIC MI|/|/Jld ■ ClUlvT dIHl C~IIlaIJ. 

Intrinsic 

6. Fax number 

Su{^iier's number 

Intrinsic 

7. Transaction cuncucy 

Supplier*s currency^ in which transactions ~ 
take place 

Intrinsic 

8. Suppons p^card? 

Boolean indicate whether this sqiplier accq>ts 
p-cards 

Intrinsic 

9. Ghosted p-card nmnber 

P-card to use when dealing \nth this supplier. 
If this field is present, die value always 
overrides die enq^yee^s p-card number. 

Intrinsic 

1 10. Transfer Method 

{ERP, Direct Order, None} 

Intrinsic 


ouppjier s teiepnone numoer 

Extrinsic 

12. URL 

Supplier's Unifonn Resource Locator 

Extrinsic 

13. Our Customer iSr 

Custcmier Number by which the siqiplier 
identifies us 

Extrinsic 

14. Buyer 

A^<!cimefl htivpr fnr nop nnlv u/hAti ttt^v^ ic a 

i"fcaa»^MwM VtMjf^M,f kUi, luC SrUMjf WJlCiU V> a 

direct order agreemem widi this siq^plier 

Intrinsic 

15. Carrier 

Supplier's preferred carrier. UPS, FedEx, 
etc. 

Intrinsic 

16. Carrier method 

2-day air, etc. 

Intrinsic 

17. Tax code 

Tied to location 

Extrinsic 

Features of One Embodiment: 

System Requirements 



1. Scalabilitv 

a. ' Provides a system that supports at least 10,000 requisitions a 

month. 

20 b, Provides a system that supports at least 20,000 suppliers. 

c- Provides a system that supports at least 35,000 employees, 
d. Provides architectural support for multq>le instances of die 
system at a single site. Each instance of the server supports only a single ERP 
instam:e. Thwe are no •roll-up* aq)abilities between multq>le instances of the 
25 server. 
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2. Supported aient Platforms 

A Java client that runs within a Web browser, with Java support. 
Tested on the following platforms and systems: 

■ MiCTosoft® Internet Explorer® 3,01 and later, on Windows NT 

4.0. 

■ Microsoft® Internet Explorer® 3.01 and later, running on 
Windows 95. 

■ Mia-osoft® Internet Explorer® 3.01 and later, running on the 
Apple Macintosh®. 

■ Netscape® Navigator® 3.01 and later, running on Wmdows NT® 


4.0. 


Macintosh®. 


Netscape® Navigator® 3.01 and lat^, running on Windows 95®. 
Netscape® Navigator® 3.01 and later, running on the Apple 

Netscape® Navigator® 3.01 and later, running on Sun Solaris. 
Netsc^® Navigator® 3.01 and later, running on HP-UX 


(HP Unix). 


3. Supported S erver Platforms 

a. Provides an uxq)lementation of the server that runs on a 
dedicated Intel® Pentium Pro system running Microsoft® Windows NT® 4.0. 
Supports the following minimum server configuration: 

■ Processor - Intel® Pentium Pro or equivalent 200 MHz or 

greater 

■ Cache Memcuy - 256 KB cache or greater 

■ Memory - 128 MB RAM or greats 
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■ StcH^e — 4 GB hard drive or greater, depending on the size of 
the database. 

b. ' Provides an implementation of the server that runs on a Sun 
5 Machine running Solaris 2.5.1, Oracle RDBMS 7.3.2.3 and the Netscape 

Enterprise Server 2.0. 1 , 

4. - Configuration 

a. Provides a template for gathering basic information about the 
10 site before the installation: host DBMS, operating system, ERF and HRMS 

interface issues, e-mail interfaces, accounting and purchasing procedures, supplier 
data, client hardware and software, supported browsers, network configuration, 
and business rules. 

b. Configure the extensible fields and ^proval rules, using a text 
15 file editor. 

5. Seeding the database 

For compatibility during the transition period, the system provides the 
ability to seed the database with requisitions that wctc 2q>proved manually, 
20 outside the system. This functionality is intended as a convenience to help a 

company transition from paper requisitions to electronic. 


25 


The system allows an administrator to ent^ a completed psper 
requisition into the system, without routing for signature. Requisitions entered in 
this way will appear in rq>orts, but will not generate any approval requests or 


wo 98/49644 PCT/US98/08407 

-50- 

notifications^ and will not be part of the Product Information Database without 
the explicit intervention of a Purchasing Agent. 

6. Standalone Systems 

This section describes features of the system that are available only to 
provide basic functionality when the system is stand-alone: when there is no ERP 
adapter present, 

a. Provides the ability to print out purchase orders and transmit 
them to the suppliw. The printed purchase orders include standard notes (such as 
the supplier's terms and conditions) and a purchase order number. This is the 
only time the system gen^tes a purchase order. 

b. Allows Purchasing Agents to modify the generated PO before it 
is sent to the supplier. 

c. Provides a user interfiace for adding suppliers, providing a 
simple version of the supplier adapter functionality. 

It should be understood that various alternatives to the embodiments of 
the invention described herein may be employed in practicing the invention. It is 
intended that the following claims define the scq)e of the invention and that the 
methods and s^paratus within the scope of these claims, the their equivalents, be 
covered thereby. 
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WHAT IS CLAIMED ISr 

1. A software system for efficient procurement of operating 
resources within an enterprise* conq>rising: 

requisition record generating means for generating a requisition record 
for a requisition, the requisition record indicating at least an opetiiing resource 
tiiat a requestor desires to purchase, the requisition record generating means 
generating the requisition record responsive to a combination of: 
iiq>ut by a requestor; and 

operating resource information in an operating resource 
information database; 

q)proval path det^mining means, responsive to the requisition record 
and to approval rules in an approval rules database, for determining an approval 
path for the requisition record, among various ones of a plurality of possible 
approvers, required to approve the requisition record; 

approval path handling means for guiding the requisition record along 
the determined ^proval path, wherein the approval path handling means 
generates a global approval indication in response to the requisition record 
successfully traversing the £^roval path. 

2. The system of claim 1, and furtfa^ comprising: 

order gen^ting means for geuCTatrng an ordw record to a supplier of 
the desired operating resource and for communicating the order to the stq)plier. 

3. The system of claim 2, wherein the requisition record includes 
an indication of the supplier. 
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1 4, The system of claim 2, wherein the order generating means 

2 includes means for determining a method of communicating the order to the 

3 supplier, responsive to a supplier database. 

1 5. Hie system of claim 1, wherein the approval path handling 

2 means determining means determines the approval path for the requisition record 

3 at least in pan in response to a purchase amount field m the requisition record. 

1 6, The system of claim 1, wherein the requisition record generating 

2 means includes means for retrieving information about the requestor from a 

3 personal profile database associated with the requestor. 

1 7. The system of claim 6, wherein the information retrieved from 

2 the personal profile includes address information rq>resenting a destination to 

3 which it is desired for the operating resource to be sent and a dqianment in 

4 which the requestor works. 

1 8. The system of claim 6, and further including means for the 

2 requestor to override the information about the requestor retrieved from the 

3 personal profrle database associated with the requestor. 


1 
2 


9. The system of claim 1, wherein the requisition record gen^ating 
means includes means for assigning a unique identifier to the requisition. 
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10* The system of claim 1, wherein tfie requisition record generatiing 
means includes means for receiving a unique identifier assigned to the requisition 
by the user via a user input means. 

11. " TTie system of claim 1, wherein the requisition record generating 
means includes: 

means for receiving an indication of a hold time from the user via a user 
input means, 

wherein die approval path handling means begins to guide the 
requisition along the approval path upon occurrence of the hold txmt. 

12. The system of claim 1, and further including: 

means for submiumg a requisition in response to the global approval 
indication; 

wherein the requisition record generating means includes: 
means for receiving an indication of a hold time from the user via a user 
input means, 

wherein the requisition submitting means submits the requisition only 
upon occurrence of the hold time. 

13. The system of claim 1, wherein the requisition record generating 
means includes: 

means for receivmg input from the requestor q)ecifying a currency unit, 

and 

means for rq)orting a purdiase amoimt for the operating resource in 
units of the specified currency unit. 
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14. The software system of claim 1 , and further comprising: 
adaptor means for retrieving data from a legacy database program; 
wherein the requisition record generating means completes fields of the 

requisition record using the data retrieved from the legacy database program, 
whereby avoiding duplication of data already available! 

15. The software system of claim 14, wherein the adaptor means 
includes a directory service adaptor for interfacing to a directory service of the 
enterprise. 

16. The software system of claim 15, wherein the ad^^tor means is 
a human resource management system adaptor for interfacing to a human 
resource management system of the enterprise. 

17. The software system of claim 16, wherein the adaptor means 
includes means for interacting to the legacy database program on a periodic basis. 

18. The software system of claim 14, wherein the adaptor means 
includes means, responsive to the global ^^proval indication, for transferring the 
requisition to an ERP system of the enterprise. 

19. The software system of claim 18, wherein the adaptor means 
furthw includes means for retrieving, firom the ERP system of the enterprise, a 
purchase order number corresponding to the requisition. 
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20. The software system of claim 18» wherein the adaptor means 
ftirther includes means for retrieving supplier information from the ERP system 
of the enterprise. 


21. The software system of claim 20, and further comprising: 
means for creating a supplier profile based on the supplier information 

retrieved from the ERP system of the enterprise. 

22. The software system of claim 1, wherein: 

the approval rules each include a predicate and a consequence; and 
the approval path det^mining means determines whether a particular 

one of the s^proval rules applies by applying the predicate to at least one field of 

the requisition record; and 

when the approval path determining means determines that a particular 

one of the approval rules applies, the approval path determining means 

determines the ^proval path with respect to that approval rule by applying the 

consequence of the approval rule. 

23. The software system of claim 1, wherein: 

the^proval rules database includes an ordCT definition of which, if any, 
required approve must approve the requisition serially and \i^ch, if any, may 
approve the requisition in parallel; and 

the approval path handling means operates responsive to die ord^ 
definition. 
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24. The system of claim 1, wherein the approval path handling 
means includes: 

notification means^ responsive to a position of the requisition record 
along the approval path, for notifying whichever approver is at that position that 
action is required to be taken on the requisition. 

25. The software system of claim 24, wherein the approval path 
handling means includes: 

status change recognition means that recognizes a change in status of the 
requisition as a result of action taken by an approver, and 

notification means, wherein the notification means operates responsive 
to the status change recognition means to notify the requestor of the status 
change. 

26. The software system of claim 1 , wherein: 

the action taken by die approver at a particular position in the ^proval 
path includes one of: 

approving the requisition; and 
denying die requisition; and 
the £q[)proval path handling means moves the requisition to a next 
position in the ^provai path req>onsive to the approver at die particular position 
approving the requisition. 

27. The software system of claim 26, wherein: 

the approval path handling means includes non-response handling 
means, responsive to an amount of time during whidi the requisition is at a 
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4 paitioilar position in the approval path without any action being taken by the 

5 approver at that position, for moving the requisition to another s^prover who has 

6 a predetermined relationship to the ^prover who took no action. 

1 28. The software system of claim 27, wherein: 

2 the predetermined relationship is indicated by chain of command data 

3 defii^ in an>^ERP database, and 

4 the system further includes an ERP adaptor for accessing the chain of 

5 command data from the ERP database. 

1 29. The system of claim 26, and further comprising: 

2 notification means, wherein in response to the requisition being moved 

3 to the next position in the approval path, the notification means notifies the 

4 approver at said next position that action is required to be taken, by that 

5 approver, on the requisition. 

1 30. The software system of claim 26, wherein: 

2 the action taken by the approve at the particular location in the 

3 q)proval path further includes: 

4 modifying at least a portion of the requisition record; and 

5 the q)proval handling means includes modification response means, 

6 operating in response to an approver modifying a requisition, for causing the 

7 approval path detwinining means to detmnines a rq)lacement approval patfi, 

8 responsive to the modified requisition. 
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31. Tht system of claim 1, wherein the q>proval path handling means 
inchides non-response handling means, responsive to a request from the 
requestor, for moving die requisition from a first approver who has taken no 
action to a second approve who has a predetermined relationship to die approver 
who took no action. 

32. The system of claim 3 1 , wherein, responsive to moving the request 
from die first £q>prover, die a^royal path handling means prevents the first 
approver from action on the requisition. 

33. The system of clann 31, wherein die predetermined relationshq) is at 
least partially defined in die s^roval rules. 


34. Hie system of claim 1, and ftirther including: 

delegation of authority means for receiving a request from a first 
^prover for delegating die audiority of the first ^prov^ to a second approver 
by configuring die approval patii handling means to modify die j^roval padi 
sudi diat the q^roval path inchides the second spprover m place of the first 
zppxav&r. 
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